home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group94b.txt / 000075_icon-group-sender _Wed Oct 19 05:47:00 1994.msg < prev    next >
Internet Message Format  |  1995-02-09  |  18KB
  1. Received: by cheltenham.cs.arizona.edu; Wed, 19 Oct 1994 06:16:29 MST
  2. To: icon-group-l@cs.arizona.edu
  3. Date: 19 Oct 1994 05:47:00 GMT
  4. From: tchrist@usenix.org (Tom Christiansen)
  5. Message-Id: <382bsk$lu5@csnews.cs.Colorado.EDU>
  6. Organization: USENIX Association, Berkeley, CA
  7. Sender: icon-group-request@cs.arizona.edu
  8. References: <Cxw8oI.Dso@usenix.org>
  9. Subject: Abstracts from Upcoming VHLL Symposium
  10. Errors-To: icon-group-errors@cs.arizona.edu
  11.  
  12. Here are some abstracts for next week's conference.
  13.  
  14.  ABSTRACTS from the upcoming USENIX Very High level Languages Symposium
  15.  
  16.                        October 26-28, 1994
  17.                        Santa Fe, New Mexico
  18.    =============================================================
  19.  
  20.            TkPerl-- A port of the Tk toolkit to Perl5
  21.  
  22.                       Malcolm Beattie
  23.             Oxford University Computing Services
  24.                   mbeattie@sable.ox.ac.uk
  25.  
  26.  
  27.     ABSTRACT: TkPerl is a port (work in progress) of the
  28.     Tk[1] toolkit to Perl5[2].  It  takes  advantage  of
  29.     Perl5's object oriented features and magic variables
  30.     to  implement  the  Tk  toolkit  in  Perl5.  Nothing
  31.     passes through the Tcl parser so  knowledge  of  Tcl
  32.     syntax  is  not  required  to  use TkPerl. TkPerl is
  33.     freeware (distributed under the GNU  General  Public
  34.     License) and is currently in alpha testing.  Section
  35.     1 of the paper introduces TkPerl and is followed  by
  36.     a  brief  section  on its target uses.. Since TkPerl
  37.     relies heavily on the object  oriented  features  of
  38.     Perl5  (which  is  itself only just into beta test),
  39.     section 3 explains how Perl5 implements classes, ob-
  40.     jects  and  methods. Section 4 discusses the differ-
  41.     ences between Tk/Tcl and TkPerl  both  at  scripting
  42.     level  and  at  C level.  Section 5 looks at some of
  43.     the porting issues and problems and how Tcl  conven-
  44.     tions  affect the design of Tk itself. Section 6 ex-
  45.     plains the current  intentions  for  the  future  of
  46.     TkPerl and section 7 gives availability information.
  47.  
  48.  
  49.            ==================================
  50.  
  51.               libscheme: Scheme as a C Library
  52.                      Brent W. Benson Jr.
  53.                    Harris Computer Systems
  54.               Brent.Benson@mail.csd.harris.com
  55.  
  56. Abstract
  57.  
  58.   Because of its small size and simplicity, Scheme is often seen as an
  59.   ideal extension or scripting language.  While there are many Scheme
  60.   implementations available, their interfaces are often complex and
  61.   can get in the way of using the implementation as part of a larger
  62.   software product.  The libscheme library makes the Scheme language
  63.   available as a C library.  Its interface is through a single C
  64.   header file and it is easily extended with new primitive procedures,
  65.   new primitive types, and new syntax.  It is portable to any system
  66.   that has an ANSI C compiler and to which Hans Boehm's popular
  67.   conservative garbage collector [1] has been ported.  It has been
  68.   used to build a variety of special purpose data manipulation tools,
  69.   and as an extension language for an ethernet monitor.
  70.  
  71.  
  72.            ==================================
  73.  
  74.         END-USER SYSTEMS, REUSABILITY, AND HIGH-LEVEL DESIGN
  75.  
  76.                Glenn S. Fowler  (gsf@research.att.com)
  77.                 John J. Snyder  (jjs@research.att.com)
  78.                 Kiem-Phong Vo  (kpv@research.att.com)
  79.  
  80.                         AT&T Bell Laboratories
  81.                          600 Mountain Avenue
  82.                      Murray Hill, NJ  07974  USA
  83.  
  84.  
  85.        During the past ten years, the number of computer  users
  86.        has grown by orders of magnitude.  This has been brought
  87.        about by dramatic increase in computing  power  combined
  88.        with   equally  dramatic  decrease  in  hardware  costs.
  89.        Beyond  "stand-alone"  user   applications   like   word
  90.        processing  and  spreadsheets,  new  classes of business
  91.        applications  arise  where  competitive   advantage   is
  92.        created by empowering "end-users" with instant access to
  93.        relevant  information.   In  many  cases,  code  already
  94.        exists  to  access  and process the desired information;
  95.        the challenge is finding a way to couple such processing
  96.        capabilities  to  individual  user requests in a timely,
  97.        specific, and friendly fashion.  The keys to  such  end-
  98.        user  systems  lie  in  high-level  design  and software
  99.        reusability.  This paper describes a language tool EASEL
  100.        (End-User  Application  System  Encoding  Language)  for
  101.        building  end-user  systems  and  experiences   in   its
  102.        development and deployment.
  103.  
  104.            ==================================
  105.  
  106.                      FEATURE-BASED PORTABILITY
  107.  
  108.  
  109.                Glenn S. Fowler  (gsf@research.att.com)
  110.                 David G. Korn  (dgk@research.att.com)
  111.                 John J. Snyder  (jjs@research.att.com)
  112.                 Kiem-Phong Vo  (kpv@research.att.com)
  113.  
  114.                         AT&T Bell Laboratories
  115.                          600 Mountain Avenue
  116.                      Murray Hill, NJ  07974  USA
  117.  
  118.  
  119.     Current computing platforms encompass a  dizzying  variety  of
  120.     hardware and software.  A software application may live or die
  121.     based on how portable it is.  Much has been written and talked
  122.     about how to enhance portability.  But few tools are available
  123.     to support writing portable code and, more importantly, to en-
  124.     code porting knowledge.  This paper describes IFFE, a tool and
  125.     an accompanying programming style that supports software  por-
  126.     tability.   IFFE  has  enabled the porting and construction of
  127.     many large software applications  on  heterogeneous  platforms
  128.     with virtually no user intervention.
  129.  
  130.                ================================
  131.  
  132. Dixie Language and Interpreter Issues
  133.  
  134. R. Stockton Gaines
  135. U. S. C. Information Sciences Institute
  136. 4674 Admiralty Way
  137. Marina del Rey CA 90292
  138. <gaines@isi.edu>
  139.  
  140. Abstract
  141.  
  142. Dixie (Distributed Internet Execution Environment) provides a base
  143. for sending programs called Dixie applications to Internet sites
  144. for execution. It provides the features generally found in operating
  145. systems, such as a file system, multiprocessing, interprocess
  146. communications, etc., and in addition capabilities to permit Dixie
  147. applications to interact with resources at the local site.  Security
  148. is of first importance; it must not be possible for a Dixie
  149. application to have an undesired effect on the local system.  This
  150. paper explains the Dixie concept and discusses language and execution
  151. issues.  The languages understood by Dixie, at least initially,
  152. will fall in the class of Very High Level Languages, not the least
  153. because these languages will support the security requirements of
  154. Dixie, as well as the command language requirements.  Dixie
  155. complements these languages, and provides uniform platform independent
  156. of the local hardware and operating systems to support Dixie
  157. application programs.
  158.  
  159.                ================================
  160.  
  161. Fornax: A General-Purpose Programming Language
  162.  
  163.   J. Storrs Hall
  164.   Laboratory for Computer Science Research
  165.   Hill Center, Busch Campus
  166.   Rutgers University
  167.   New Burnswick, NJ  08903
  168.   <josh@cs.rutgers.edu>
  169.  
  170. [Fornax, ``the Furnace,'' is an obscure Southern Hemisphere constellation
  171.   between Cetus and Eridanus.]
  172.  
  173. Abstract
  174.  
  175. Fornax is a very high-level programming based on pattern-matching
  176. concepts from Snobol (and Icon) and array or "data-parallel" concepts
  177. from APL (and J).
  178.  
  179.         ===============================
  180.  
  181. An Application Experience with
  182. an Implicitly Parallel Composition Language
  183.  
  184. R. Jagannathan and Chris Dodd
  185. SRI International
  186. Computer Science Laboratory
  187. 333 Ravenswood Avenue
  188. Menlo Park, California 94025
  189. {jaggan,dodd}@csl.sri.com
  190.  
  191. Abstract:
  192.  
  193. We describe our experiences with a very high-level parallel
  194. composition language (called GLU) that enables rapid construction of
  195. parallel applications using sequential building blocks (extracted from
  196. existing sequential applications) and their execution on diverse
  197. parallel computer systems.  GLU is sufficiently rich to succinctly
  198. express different forms of parallelism --- from function parallelism
  199. to data parallelism and from pipeline parallelism to tree parallelism.
  200. We show by example how a typical sequential application can be
  201. converted to a parallel one in GLU and executed on different parallel
  202. systems.  We also show how GLU has been used to convert two widely
  203. used sequentially written, inherently parallel workstation
  204. applications --- the make utility and a raytracing system --- to
  205. parallel equivalents that can then be run much faster on a network of
  206. workstations.
  207.  
  208.  
  209.         ===============================
  210.  
  211.          Graphics Programming in Icon Version 9
  212.  
  213.                 Clinton L. Jeffery
  214.                 Division of MCSS,
  215.                 The University of Texas San Antonio, TX 78249, U.S.A.
  216.                 E-mail: jeffery@ringer.cs.utsa.edu
  217.  
  218.                 Ralph E. Griswold and Gregg M. Townsend
  219.                 Department of Computer Science,
  220.                 The University of Arizona, Tucson, AZ 85721, U.S.A.
  221.                 E-mail: {ralph|gmt}@cs.arizona.edu
  222.  
  223.  
  224.                                 Abstract
  225.  
  226. Version 9 of the Icon programming language introduces support for graphics
  227. and user interface programming as an extension of the existing file-based
  228. input/output model, rather than introducing graphics as a disjoint facility.
  229. Simplicity, generality, and portability are the primary emphases.  The
  230. result is a language in which common graphic effects are easy to write using
  231. ordinary procedural code.  Complex techniques such as event-driven
  232. programming are optional and not forced on the programmer when they are not
  233. needed.
  234.  
  235.            ==============================================
  236.  
  237.                An anecdote about ML type inference
  238.  
  239.             Andrew Koenig (ark@research.att.com)
  240.                    AT&T Bell Laboratories
  241.                Murray Hill, New Jersey  07974
  242.  
  243. Introduction
  244.  
  245. ML strongly supports functional programming; its programmers
  246. tend to avoid operations with side effects.  Thus, for
  247. example, instead of mutable arrays, ML programmers usually
  248. use lists.  These lists behave much like those in Lisp, with
  249. the added requirement that all elements have the same type.1
  250. ML lists are not themselves mutable, although the individual
  251. elements can be of a (uniform) mutable type.  In Lisp terms,
  252. ML lists can optionally support RPLACA but not REPLACD.
  253. Although it is possible to define a type in ML that would
  254. support REPLACD as well, ML programmers usually don't do
  255. this unless they need it.
  256.  
  257.          ========================================== 
  258.  
  259.              ksh - An Extensible High Level Language
  260.  
  261.              David G. Korn (dgk@research.att.com)
  262.                   AT&T Bell Laboratories
  263.                  Murray Hill, N. J. 07974
  264.  
  265.  
  266.            ksh is a high level interactive script language  that  is  a
  267.            superset   of   the  UNIX  system  shell.   ksh  has  better
  268.            programming features and better  performance.   Versions  of
  269.            ksh  are  distributed  with the UNIX system by many vendors;
  270.            this has created a large and growing user community in  many
  271.            different companies and universities.  Applications of up to
  272.            25,000 lines have been written in ksh and are in  production
  273.            use.
  274.  
  275.            ksh-93 is the first major revision of  ksh  in  five  years.
  276.            Many of the changes for ksh-93 were made in order to conform
  277.            to the IEEE POSIX and ISO  shell  standards.   In  addition,
  278.            ksh-93  has many new programming features that vastly extend
  279.            the power of shell programming.  It was revised to meet  the
  280.  
  281.          ========================================== 
  282.  
  283.  
  284. Application Languages in Software Production
  285.  
  286. David A. Ladd
  287. <ladd@research.att.com>
  288. J. Christopher Ramming
  289. <jcr@research.att.com>
  290. AT&T Bell Laboratories
  291.  
  292. 1    Introduction
  293.  
  294. PRL5 is an application-oriented language used to maintain the integrity of
  295. databases in the AT&T 5ESSTM telecommunications switch.  PRL5 is unusual
  296. in that it was explicitly designed to eliminate a number of different coding
  297. and inspection steps rather than simply to improve individual productivity.
  298. Because PRL5 replaced an earlier high-level language named PRL, which in
  299. turn replaced a combination of English and C on the same project, it is
  300. possible to trace the effect of several fundamentally different languages on
  301. this single project.  The linguistic evolution has been away from languages
  302. describing computation toward a "declarative" high-level language that has
  303. been deliberately restricted to accommodate the requirements of certain
  304. analyses.
  305.  
  306. Algorithms for checking database constraints are no longer specified by human
  307. developers; instead, code is generated from static representations of the
  308. constraints themselves. These constraint descriptions can be used in more
  309. than one way, whereas a program to check constraints is useful only for
  310. performing that particular computation. In effect, PRL5 allows the re-use of
  311. project information at a high level, before it has been specialized into
  312. particular implementations. 
  313.  
  314. The effects of this re-use on quality, interval, and cost are tangible.
  315. A key lesson is that application-oriented languages should not be designed to
  316. describe computation, they should be designed to express useful facts from
  317. which one or more computations can be derived.
  318.  
  319.          ========================================== 
  320.  
  321. Using Tcl to Control a Computer-Participative Multimedia
  322. Programming Environment
  323.  
  324. Christopher J. Lindblad
  325. Telemedia Networks and Systems Group
  326. Laboratory for Computer Science
  327. Massachusetts Institute of Technology
  328.  
  329. Abstract
  330.  
  331. This paper describes how the VuSystem, a programming environment for
  332. the development of computer-participative multimedia applications, is
  333. controlled through Tcl scripts.  In the VuSystem, networks of in-band
  334. media-processing modules are created and controlled by interpreted
  335. out-of-band Tcl scripts through object commands and callbacks.  Tcl's
  336. extensibility, simple type system, efficient interface to C, and
  337. introspective capabilities are used by the VuSystem to produce a
  338. highly dynamic and capable media processing system.
  339.  
  340.     ============================================
  341.  
  342.         Using  a  Very  High  Level  Language  to  Build  Families  of High
  343.                       Quality  Reusable  Components
  344.  
  345.                               Gary F. Pollice
  346.                        CenterLine Software, Inc. and
  347.                           U. Massachusetts, Lowell
  348.  
  349. 1 Introduction
  350.  
  351. While most programs are designed to perform a specific task, they have a
  352. natural evolution over time; causing a single program to become a set of
  353. programs that perform related tasks.  In 1976 David Parnas introduced the
  354. concept of a family of programs [11 ].  He suggests that any program should
  355. be considered a member of a family of programs, all of which perform
  356. related tasks.  If one plans for change when a program is designed less
  357. effort may be required to produce future revisions.  Today there is an
  358. emphasis on building software components for reuse.  Components may be
  359. designs, programs, functions, classes, or code segments.  Major reuse
  360. projects are in progress at several institutions, for example, the
  361. Software Productivity Consortium and the Software Engineering Institute
  362. [1,6 ].  Processes have been developed to introduce and support reuse
  363. programs.  The disciplines of domain engineering and software synthesis
  364. emphasize creating families of components and developing tools to assist in
  365. constructing them.  Component generation is a prominent part of most
  366. efforts.
  367.  
  368.     ============================================
  369.  
  370.  A New Architecture for the Implementation of Scripting Languages
  371.  
  372.                     Computer Science Division
  373.            Electrical Engineering and Computer Sciences
  374.                      University of California
  375.                         Berkeley, CA 94720
  376.                    {asah,blojo}@cs.Berkeley.EDU
  377.  
  378.                         September 12, 1994
  379.  
  380.                             Abstract
  381.  
  382.      Nearly all scripting languages today are implemented as
  383.      interpreters written in C. We propose an alternate
  384.      architecture where the language is translated into the
  385.      dynamic language Scheme [R4RS].  The plethora of high
  386.      quality, public domain Scheme implementations give the
  387.      developer a wide selection of interpreters, byte
  388.      compilers, and machine code compilers to use as targets
  389.      for her VHLL.
  390.  
  391.      Our VHLL, Rush, provides high-level features such as
  392.      automatic type conversion and production rules
  393.      [SHH86][Ston93].  Performance benchmarks show that our
  394.      system runs with acceptable speed; in fact, Rush programs
  395.      run much more quickly than their equivalents in languages
  396.      such as Tcl and Perl4.  Whereas those languages are coded
  397.      in C, Rush takes advantage of Scheme's existing high-level
  398.      features, saving de- velopment time.  Since the features
  399.      provided by Scheme are among those most VHLLs share, we
  400.      expect this approach to be widely applicable.
  401.  
  402. *supported in part by a grant from the National Science Foundation
  403.  #NSF-IRI9107455
  404.  
  405.  
  406.  
  407.  
  408.  
  409.  
  410.  
  411.  
  412.